In this blog, you will explore the Cluster LifeCycle capabilities of Red Hat® Advanced Cluster Management for Kubernetes (RHACM), Creating Application Deployments and Governance Risk Policies (GRC).
-
Understand the functions of hub and managed clusters.
-
Understand Cluster Lifecycle capabilities.
-
Import an OpenShift® cluster to RHACM.
-
Understand Application Lifecycle capabilities in RHACM.
-
Deploy an application to a managed cluster.
-
Understand GRC in RHACM.
1. Introduction
RHACM allows you to manage many Kubernetes clusters from a single location. While the concept of a stretch cluster is something that is often requested, the complexity and potential problems that come with it due to conditions that are beyond the cluster’s control—such as network latencies—usually outweigh the perceived benefits. The preferred approach is multiple clusters—which can be large or small—that are centrally managed. Red Hat Advanced Cluster Management provides this functionality and more.
Within the RHACM web console, there are four main sections that you use to manage different aspects of your Kubernetes clusters and workloads.
2. Review Architecture
Your hub cluster only does one thing—it runs RHACM. All of the RHACM components that provide functionality for the Cluster Lifecycle, Application Lifecycle, and Governance, Risk, and Compliance (GRC) features run on this cluster. Your hub cluster cannot be managed. If you were to try to add the hub cluster as a managed cluster, you would see an error message and that action would be prevented. Do not attempt this.
Your managed cluster also does one thing—it runs your workloads. Customer application workloads are obviously going to run here, but managed clusters also run the RHACM endpoint components. These endpoint components are deployed as Pods and scheduled to run on nodes in the cluster just as any other application would.
RHACM employs a pull-based architectural model that relies on an agent in the cluster joining an external management plane. This architecture has emerged across the Kubernetes and GitOps ecosystem, and it is where Red Hat has focused its upstream and product investments. The endpoint that you deploy onto the managed cluster communicates with RHACM running on the hub cluster.
While a managed cluster can be either OpenShift or another flavor of Kubernetes, the hub cluster can only be deployed on OpenShift. In this lab, both clusters are deployed in a supported cloud provider. The cloud provider may be different depending on when and where you are doing this lab. This does not really matter because everything in the cloud provider that you need is abstracted for you by OpenShift.
Your clusters are slightly different in size. Each one has three master nodes to provide a highly available control plane. Your hub cluster has three workers, while your managed cluster only has two. This is due to the resources required by the RHACM components and can be further tuned. For instance, by using larger worker instances, the number of worker nodes could be decreased in quantity.
2.1. Review Cluster LifeCycle functionality
The Cluster Lifecycle feature in RHACM allows you to manage the deployment, deletion, importing, and upgrading of your Kubernetes clusters within the following parameters:
Deploying new OpenShift clusters to supported platforms. This includes Amazon Web Services, Microsoft Azure, and Google Cloud. Bare metal is included as a tech preview feature.
Deleting or destroying an OpenShift cluster that was deployed by RHACM. You cannot destroy a cluster that you imported, but you can remove it from RHACM if you no longer want to manage it.
Importing existing Kubernetes clusters. This is not limited to any specific platforms.
Upgrading managed OpenShift clusters.